Description

Reason for the change:

On Android, when a user changes their biometric enrollment (or due to an Android 16 Keystore behavioral change), the Keystore key backing the vault backup entry can be permanently invalidated. In that state, getInternetCredentials(VAULT_BACKUP_KEY) throws an exception rather than returning false/undefined. Because that call sat inside the outer try/catch in backupVault, the thrown error was caught at the top-level catch, which logged "Vault backup failed" to Sentry and returned { success: false } — even though the underlying vault was fine and a fresh backup could have been written successfully.

Solution:

Wrap the initial getInternetCredentials read in its own inner try/catch. If the read throws (key invalidated), we:

1. Log a non-error warning via Logger.log (no Sentry noise)
2. Clear any corrupted keychain entries with clearAllVaultBackups()
3. Fall through to write a fresh backup normally

This makes backupVault resilient to stale Android Keystore state and prevents a false "Vault backup failed" from ever surfacing when the real backup operation can succeed.

Changelog

CHANGELOG entry: Fixed an issue on Android where vault backup could silently fail after a biometric enrollment change or Keystore key invalidation

Related issues

No issue: bug surfaced via Sentry report (extra.message: "Vault backup failed") — Android Keystore key invalidation causing getInternetCredentials to throw inside backupVault

Manual testing steps

Feature: Vault backup resilience on Android

  Scenario: Vault backup succeeds even when existing backup read throws due to Keystore invalidation
    Given the user has a MetaMask wallet set up on Android
    And a vault backup already exists in the keychain
    And the Android Keystore key has been invalidated (e.g. by adding/removing biometric enrollment)

    When the vault backup routine is triggered (e.g. on wallet unlock or state change)
    Then the backup should complete successfully
    And no "Vault backup failed" error should appear in Sentry
    And the user should not be prompted with an error or crash

Note: This fix is primarily defensive for an Android Keystore edge case. Manual reproduction requires a device where biometrics have been changed after the backup was created, or an Android 16 device exhibiting the Keystore regression. Unit test coverage added for the throwing path.

Screenshots/Recordings

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

Made with Cursor